The present invention relates to automated personal name addressing in a multimedia messaging environment.
Unified communications systems combine the functionality of a centralized voice/fax/e-mail messaging system (i.e. a unified messaging system, such as the Intuity(copyright) or AnyPath(copyright) system of Lucent Technologies Inc.) with the functionality of a live communications network (e.g., the public switched telephone network or a private branch exchange) to enable subscribers to reply to calls or messages, or to make calls or send original messages. In a unified communications system, messages in the form of e-mail are common. E-mail addressing typically requires the entry of alpha-numeric strings, including special characters that are not normally found on the keypad of a telephone. Because the entry of alpha-numeric strings and special characters from a telephone is at best cumbersome, most unified communications systems restrict the addressing of messages originating from a telephone interface with the unified communications system to those addresses that have been preadministered in a system directory, or that can be identified uniquely by a telephone number. Therefore, providing a convenient messaging system in a unified communications system typically requires the association of message addresses with the names of recipients by a directory administrator. Although the creation of such a directory is feasible in a corporate environment where the directory generally includes only employees of the enterprise, such a solution is not available to users requiring address directories made up of addressees outside of the enterprise.
In the enterprise environment, a shared system directory that is prepared by a directory administrator and that is searchable by the name of the addressee generally allows a user to locate a desired address by speaking or otherwise entering the addressee""s name, without the need to enter a complicated address. However, these techniques are not scalable into the service provider or Internet markets because the concept of sharing a corporate directory to improve internal corporate communications does not apply to individuals who subscribe to service provider services. Also, a comprehensive directory could produce so many hits (or matches) upon entering a name that disambiguation of the returned addresses would often be too complicated and time consuming for the common user. Furthermore, the creation of a unified directory in a geographic area for use by individual consumers would be inefficient, as the vast majority of the addressees included in such a directory would be of no interest to other local consumers. In addition, such a directory would be unreliable, since it would be in a nearly constant state of change, and since there would be no ability to validate new addresses, as no single authority exists for the assignment of all of the various forms of addressing that may be accessible through a unified communications system.
In order to enable e-mail addresses to be entered from a telephone, voice mail vendors have attempted to map telephone numbers to e-mail mailboxes. However, such schemes become untenable when there is not a one-to-one correspondence between telephone numbers and e-mail addresses. Computer application programs providing personal address books are available, however, these programs generally require manual pre-administration by the user, and users are not inclined towards completing tasks ahead of time that are not directly related to a communications scenario. Therefore, existing systems provide no satisfactory method of automatically creating a personal directory of addresses for use by individual subscribers of unified communications systems.
The present invention is directed to solving these and other problems and disadvantages of the prior art. Generally, according to the present invention, an address repository or communications log is maintained on the unified communications system server on behalf of each subscriber. The communications log includes a name and address pair for each communication scenario, such as a phone call, a voice mail, a fax message, an Internet phone call, an e-mail or instant messaging service message, that is received or sent by the subscriber using any communications channel monitored by the server and having an address associated with the subscriber. When the communications scenario involves a message, the name and address pair may be collected by parsing the header information associated with the message. When it involves an incoming call, the name and address (number) information may be derived from the network call set-up message (e.g. SS7-1SUP, ISDN, or caller identification (caller ID)) information conventionally received as part of the telephone answering scenario. The address (number) associated with outgoing voice or facsimile telephone calls made while connected to the unified communications system may be collected, and a name associated with each number by either referring to a network for number-to-name mapping, or by prompting the subscriber to record a brief voice tag to associate with the number. This voice tag would be used in place of the text-name confirmations when confirmations are played. It would also serve as a prompt for entering a text-name at a later time when accessing the universal communications server using a text-capable instrument such as a P.C.
In a further embodiment, more complete telephony integration techniques can be employed to capture both dialed call information and incoming call information for telephony call scenarios that are completed without involving the unified communications system. For example, the name and telephone number pair associated with a call to or from the subscriber""s telephone may be collected by a telephony circuit switch operating in cooperation with the unified communications server. If the switch collects only a number, the universal communications server can perform a reverse phone number look up on the network to obtain the associated name. Name and address pairs so collected may then be automatically added to the communications log. It is important that these name/address pairs be stored together in the subscriber""s communication log so that the search scope is limited for touch tone look-up and voice recognition look-up.
The individual subscriber may also add entries to a server side personal address book using a graphical user interface to enter name, e-mail address, voice and facsimile telephone number information and other addressing information in a conventional manner. Name and address pairs entered by the subscriber in the personal address book are automatically made a part of the communications log. Also, using a graphical user interface, previously captured number/voice tag pairs can be revised to have a full text-name added.
The communications log is intended to be used as a directory by a variety of client devices or applications in support of their associated name-addressing and name-dialing scenarios. These clients include standard e-mail clients, which access the communications log via a standard lightweight directory access protocol (LDAP) interface, dual tone multiple frequency (DTMF) telephone user interfaces, which access the directory by entering the DTMF key spelling of the recipient""s name, voice command telephone user interfaces, which access the directory by speaking the name of the recipient, and web-based graphical user interfaces, which access the directory by typing a partial name or by scrolling through the log to pick a recipient.
A web-based graphical user interface may also be used to directly enter, modify, or validate the entries in the communications log. For example, this communications log administrative user interface may be used to import the contents of a personal address book into the communications log. It may also be used to directly administer new entries into the log, or to complete partial entries in the log such as entries with only voice-tags that require text names to become complete name address pairs.
The purpose of all name addressing and name dialing scenarios is to select the exact address associated with the proposed name and to provide a confirmation back to the user that the appropriate address has been selected. Since the contents of the communications log evolves automatically as it tracks each new communications event, and since name matching using DTMF key spelling or voice command input can produce multiple matches for a single proposed input, the matched addresses might seem unpredictable without a mechanism to stabilize and prioritize the results.
A re-usability level and a use count is maintained for each name address pair in the communications log to ensure more predictable results on frequently used addresses. When the communications log is searched by name, the scope of the search may be confined to particular reusability levels. For example, a focused search may include only levels one and two, whereas an expanded search (typically used when a correct address is not found in the focused search) may include only levels three through six. Levels seven and eight are always excluded from name searches, but exist in the communications log to prevent failing or erroneous addresses from re-appearing in the log. When a search produces multiple results, the results are returned in priority order first by re-usability level and then by use count. This arrangement ensures that a single appropriate address will be returned on the first attempt in the majority of uses. A subscriber may also access his or her communications log through other interfaces that may be available, such as a computer graphical user interface interconnected to the communications server.